1. Field of the Invention
This invention relates to state data management methods and systems for client-server and transaction processing computing arrangements.
2. Description of the Related Art
IBM originally developed Customer Information Control System (“CICS”) to provide online transaction processing (“OLTP”) programs for its mainframe computer systems. Today, together with COBOL programming language, a very large number of legacy applications still use the COBOL/CICS applications and environment to process transactions by accessing business data such as orders, inventory records and customer data.
CICS controls the interaction between application programs and the users of the system, and CICS allows programmers to develop screen displays without detailed knowledge of the terminals which will be used by the users. Using an application programming interface (“API”), developers can write programs to access business data in a database to maintain data integrity. In fact, current business application programs written in billions of COBOL lines facilitate more than 20 billion online transactions per day. Despite the attention in the computing industry being made to newer languages such as C++ and Sun Microsystems Java™, COBOL/CICS actually still has the largest installed base of applications. Therefore, it is still important for the CICS computing environment to be advanced to meet new customer requirements and needs.
The CICS products can reside on many types of operating systems such as OS/390 and UNIX, running on a wide variety of computing hardware platforms such as IBM's iSeries Enterprise servers or IBM-compatible Personal Computers. The latest IBM CICS Transaction Server for z/OS™, Version 2.3, offers an array of features and functionalities. It provides an efficient and effective environment for applications written in COBOL, PL/I, C, C++ and Java. This version strengthens application development capabilities, enables enhanced re-use of 3270 applications, and enables applications to be accessed as Web Services within a services oriented architecture (“SOA”).
The CICS Transaction Server provides a robust, high performance environment for enterprise applications written in Java, as well as COBOL. In other words, it supports Enterprise Java Beans (“EJB”) session beans that provide another dimension for application architects. Where an EJB component needs to incorporate procedural logic modules to accomplish its business function, CICS enables this mixed-language component to run in a single execution environment with good isolation from other components, improving robustness and manageability.
In addition, CICS allows for a run-time environment optimized for business logic written as EJBs that can run alongside, and interoperate with, business logic written in other languages such as COBOL. Both EJB and COBOL applications can access existing and new databases such as DB2, IMS™ and VSAM data, concurrently, and with complete integrity.
Furthermore, CICS Transaction Server contains enhancements for applications that use TCP/IP communication for e-business enablement. These offer a range of benefits in terms of management and improved scalability and performance. Enhancements such as DB2 facilities provide a significant improvement in performance and greater level of availability. In summary, CICS assists in the evolution to on-demand computing through integration, open architecture, autonomic computing and virtualization.
Turning to FIG. 7, a CICS environment and process is depicted in a general or high-level manner, which a number of client systems, consoles or terminals (71, 72, 73) are provided processing by an OLTP server (74) via a communications network (70) and a web server (75). Each OLTP process or instance of an OLTP process is associated with one or more state data blocks. State data blocks may store transaction data, session data, or combinations of the two. The associated web server blocks can provide some business logic, as well as user interface functions (e.g. forms, screens, etc.).
For example, a bank may have several teller consoles located throughout the bank. The teller consoles, which are the end-user clients (71, 72, 73) in this scenario, can be used to establish a new banking account for a new bank customer. In this example, a teller uses a console (71) to enter information into screens or forms, which drive an OLTP process to create the new bank account, entering information such as the customer's personal data (name, address, telephone number, etc.), and account options (e.g. checking, savings, investment, etc.). Forms and screens may be created and provided by the web server process associated with the teller console being used. The data, however, is stored in state data 1, which is associated with OLTP process 1 and web process 1. The information which the teller inputs is accumulated in the state data block. In this example, the OLTP process creates, or generates, a state data token that is associated with the state data. The state data token is passed to the client and is returned with sequent requests from the client to assure that only the appropriate client device is allowed to use the state data associated with that client.
Although the existing technology, relating to state data token generation and state data management, fulfills much of online transaction processing needs in the industry, it does not handle high transaction volumes as effectively or efficiently as possible. In fact, current methods do not scale as well as possible with high transaction loads which adversely affects response time.
Contributing factors to poor scalability may be attributed to either instruction path length or I/O overhead in a state data access method, or the need for process or resource serialization.
Randomly generated tokens used as keys to access state data in an indexed data base require the data base to employ an index search algorithm and record update locking technique. The record locking technique is a form of resource serialization.
Methods employing state data chained in main memory require process serialization for token generation, state data access, and purging of expired state data.
For these reasons, there exists a need to provide a state data access control mechanism which exhibits improved scalability to handle a high volume of transactions in a system or OLTP environment such as CICS.